home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part1 / 8361 < prev    next >
Encoding:
Text File  |  1996-08-05  |  1.7 KB  |  43 lines
  1. Newsgroups: comp.lang.c
  2. Path: news.sprintlink.net!eskimo!scs
  3. From: scs@eskimo.com (Steve Summit)
  4. Subject: Re: HELP : handling segmentation fault
  5. X-Nntp-Posting-Host: eskimo.com
  6. Message-ID: <Dnp5Gv.2J8@eskimo.com>
  7. Sender: news@eskimo.com (News User Id)
  8. Organization: schmorganization
  9. References: <4h4h3c$c5o@dingo.cc.uq.oz.au>
  10. Date: Sun, 3 Mar 1996 14:55:42 GMT
  11.  
  12. In article <4h4h3c$c5o@dingo.cc.uq.oz.au>,
  13. s224539@student.uq.edu.au
  14. (Sahid) writes:
  15. > Does anyone can explain me how to handle the following error message ?
  16. > Program received signal SIGSEGV, Segmentation fault... at tsp.c:373
  17. > 367 conflict check_control_in_t(partitions huge timetable[], meetings huge scs[],int t){
  18. > 368    unsigned int i,j,scs1,scs2;
  19. > 369    conflict result={0,0,0},scs12;
  20. > 370
  21. > 371    // calculate student and lecturer conflicts ...
  22. > 372    for(i=0;i<timetable[t].no_scs-1;i++){
  23. > 373        scs1=timetable[t].index_scs_list[i];
  24.  
  25. The most likely cause is that the index_scs_list field of the
  26. t'th instance of the timetable array is not properly allocated.
  27. You didn't show us the definition of this structure (you should
  28. have!), but if it's a pointer as opposed to an array, to allow
  29. dynamic allocation, it's likely that it wasn't allocated
  30. correctly.  It's also possible that timetable[t].no_scs has a
  31. bogus value (causing i to range wildly), or, less likely, that
  32. the timetable array itself is improperly allocated.
  33.  
  34. If the code which sets timetable[t].index_scs_list looks normal,
  35. then it's likely that some part of the data structure is being
  36. corrupted due to a stray pointer reference due to a bug somewhere
  37. else.  (These are more frustrating and harder to track down.)
  38.  
  39.                     Steve Summit
  40.                     scs@eskimo.com
  41.  
  42. P.S. I like your variable names.
  43.